fix(accounts): store Dunning overdue outstanding in transaction currency#1
Open
devansh19299 wants to merge 2 commits into
Open
fix(accounts): store Dunning overdue outstanding in transaction currency#1devansh19299 wants to merge 2 commits into
devansh19299 wants to merge 2 commits into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refs frappe#56006
Fix: Incorrect Dunning Outstanding Amount for Foreign-Currency Invoices
The Problem
When a Dunning is created from a foreign-currency Sales Invoice whose receivable (
debit_to) account is in the company currency (i.e.,party_account_currency != currency), the overdue payment outstanding displays both the wrong value and the wrong currency label.Root Cause
In
create_dunning→postprocess_dunning(located inerpnext/accounts/doctype/sales_invoice/mapper.py), the mappedOverdue Payment.outstandingfor a single payment-schedule row was being overwritten withSales Invoice.outstanding_amount.Because
outstanding_amountis tracked in the party account currency—which in this scenario is the company currency—a company-currency figure was forced into a transaction-currency field. This incorrect value then propagated intototal_outstandingandgrand_total.Note: This behavior was introduced by frappe#41817 (commits
04f0c96af7,b7c3fa23d2) to reflect the live invoice outstanding. While the intent was valid, the currency distinction was missed. The bug remained hidden in existing tests because they only covered the common case whereparty_account_currency == currency.The Fix
The fix introduces conditional logic to handle mixed currencies properly:
party_account_currency != currency): UsePayment Schedule.outstandinginstead ofoutstanding_amount. This field is already in the transaction currency and is kept current with payments.party_account_currency == currency): Continue usingoutstanding_amountto preserve the intended behavior of fix: use invoice outstanding on Dunning frappe/erpnext#41817.Test Coverage
The following tests have been added to
test_dunning.pyto ensure stability and prevent regressions:test_dunning_outstanding_in_transaction_currency: Tests a foreign-currency invoice against a company-currency receivable. Asserts the dunning row carries the transaction-currency amount, not theoutstanding_amount. (Note: This test fails without this PR).test_dunning_outstanding_same_currency_no_regression: Guards the logic introduced in fix: use invoice outstanding on Dunning frappe/erpnext#41817 to ensure it still functions properly for same-currency invoices.test_dunning_multi_installment_foreign_currency: Ensures that multi-row payment schedules retain their correct transaction-currency values.